Process model for the development of system requirements specifications for railway systems

In this paper a process model for the development of system requirements specifications for railway systems is introduced. Demands of the approval of system requirements specifications, which arise from recent European railway standards, are taken into account. The aim is to obtain a system specification, which is unambiguous and easy to understand for all parties involved and in which safety aspects are considered in detail. Correlations between the development of a precise system specification, the performance of safety relevant correctness checks and the performance of risk analysis are presented. Especially the identification, specification and formalisation of safety requirements are treated with regard to correctness checks referred to safety aspects by using model checking. It is also demonstrated how different techniques of risk analysis can be supported by a system model in diagrams of the Unified Modelling Language (UML). This work has been developed in close co-operation with the Institute of Railway Systems Engineering and Traffic Safety (IfEV), Technical University of Braunschweig, Germany within the scope of the project SafeRail (see http://www.ias.uni-stuttgart.de/projekte/saferail/)

Retinal Axonal Loss Begins Early in the Course of Multiple Sclerosis and Is Similar between Progressive Phenotypes

To determine whether retinal axonal loss is detectable in patients with a clinically isolated syndrome (CIS), a first clinical demyelinating attack suggestive of multiple sclerosis (MS), and examine patterns of retinal axonal loss across MS disease subtypes.Spectral-domain Optical Coherence Tomography was performed in 541 patients with MS, including 45 with high-risk CIS, 403 with relapsing-remitting (RR)MS, 60 with secondary-progressive (SP)MS and 33 with primary-progressive (PP)MS, and 53 unaffected controls. Differences in retinal nerve fiber layer (RNFL) thickness and macular volume were analyzed using multiple linear regression and associations with age and disease duration were examined in a cross-sectional analysis. In eyes without a clinical history of optic neuritis (designated as "eyes without optic neuritis"), the total and temporal peripapillary RNFL was thinner in CIS patients compared to controls (temporal RNFL by -5.4 µm [95% CI -0.9 to--9.9 µm, p = 0.02] adjusting for age and sex). The total (p = 0.01) and temporal (p = 0.03) RNFL was also thinner in CIS patients with clinical disease for less than 1 year compared to controls. In eyes without optic neuritis, total and temporal RNFL thickness was nearly identical between primary and secondary progressive MS, but total macular volume was slightly lower in the primary progressive group (p<0.05).Retinal axonal loss is increasingly prominent in more advanced stages of disease--progressive MS>RRMS>CIS--with proportionally greater thinning in eyes previously affected by clinically evident optic neuritis. Retinal axonal loss begins early in the course of MS. In the absence of clinically evident optic neuritis, RNFL thinning is nearly identical between progressive MS subtypes

Technique of specification of functional safety requirements for industrial automation systems in temporal logic

Durch formale Verifikation kann die Einhaltung funktionaler Sicherheitsanforderungen im Modell der Systemfunktionen eines Automatisierungssystems mit Sicherheitsverantwortung mit mathematischer Exaktheit überprüft werden. Eine Voraussetzung hierfür ist, dass die Sicherheitsanforderungen in einer formalen Spezifikationssprache, d. h. mit einer eindeutigen Syntax und Semantik, formuliert werden. Eine entscheidende Ursache für die wenig verbreitete Anwendung formaler Verifikation liegt in der Schwierigkeit der formalen Spezifikation temporaler Relationen, die bei der Formulierung funktionaler Sicherheitsanforderungen für Automatisierungssysteme ausgedrückt werden müssen. Wird die formale Spezifikationssprache nicht vollständig beherrscht, werden Sicherheitsanforderungen leicht fehlerhaft spezifiziert, woraus die Entwicklung eines Automatisierungssystems resultieren kann, von dem Gefahren ausgehen. Dasselbe ist der Fall, wenn eine Sicherheitsanforderung falsch interpretiert wird. Diesen Schwierigkeiten kann durch ein Verfahren begegnet werden, bei dem Expertenwissen für die formale Spezifikation von funktionalen Sicherheitsanforderungen vermittelt wird. Dies wird durch die Adaption und Nutzung von aus der Softwaretechnik bekannten Wiederverwendungskonzepten erreicht. Mithilfe des daraus resultierenden Safety-Pattern-Konzepts wird die Formalisierung funktionaler Sicherheitsanforderungen vereinfacht, indem Safety-Pattern mit generischen formalen Spezifikationen verwendet werden. Die Safety-Pattern, die für das jeweilige Spezifikationsproblem geeignet sind, müssen aus einem Katalog selektiert werden. Die korrekte Interpretation von Sicherheitsanforderungen, die mithilfe von Safety-Pattern spezifiziert worden sind, wird unterstützt, indem die Bedeutung im Safety-Pattern-Katalog nachgeschlagen werden kann. Um alle Arten funktionaler Sicherheitsanforderungen spezifizieren zu können, wurde der Katalog so entwickelt, dass er durch die Verwendung einzelner generischer Formulierungen sowie durch deren Komposition eine vollständige Grundlage zur Spezifikation aller Arten funktionaler Sicherheitsanforderungen für Automatisierungssysteme bietet. Darüber hinaus enthält der Katalog generische Formulierungen, durch welche die Handhabbarkeit des Verfahrens gewährleistet wird. Durch die Verwendung einer Safety-Pattern-Normsprache wird neben der formalen Spezifikation eine präzise und einfach interpretierbare Spezifikation funktionaler Sicherheitsanforderungen in einer eingeschränkten Terminologie der natürlichen Sprache ermöglicht. Zudem wurde eine spezielle grafische Notation für die Veranschaulichung komplizierter logischer Zusammenhänge entwickelt. Durch ein Werkzeugkonzept und den Einsatz multimedialer Techniken (Interaktionen, textuelle sowie grafische Beschreibungen und Simulationen) wird die Selektion, Interpretation und Instanziierung der Safety-Pattern unterstützt. Durch das Fallbeispiel „Eingleisiger Bahnübergang im Funk-Fahr-Betrieb“ wird die Anwendung des Verfahrens für die Entwicklung sicherer Automatisierungssysteme demonstriert.For industrial automation systems with safety responsibility it is of vital importance to check the compliance of functional safety requirements. By means of formal verification it is possible to check with mathematical exactness if functional safety requirements are preserved in a model of the system functions. As a precondition, the safety requirements have to be specified in a formal specification language, i.e. that they are formulated with unambiguous syntax and semantics. It is highly challenging to specify formally temporal relations, which is compulsory for functional safety requirements of industrial automation systems. This is a decisive reason for the very rare use of formal verification. If the formal specification language is not mastered completely, then safety requirements will easily be falsely specified or will easily be misinterpreted. As a consequence unsafe industrial automation systems might be developed. Theses difficulties can be tackled by a technique, in which expertise on formal specification of functional safety requirements is imparted. This is achieved by adapting and utilizing reuse concepts, known from software engineering. The resulting safety patterns concept allows to simplify the formalisation of functional safety requirements as safety patterns with generic formal specifications are used. The safety patterns which are suitable for the respective specification problem have to be selected from a catalogue. The correct interpretation of safety requirements which have been specified on the basis of safety patterns is supported by the possibility to check their meaning in the safety patterns catalogue. The catalogue represents a complete basis for specifying all kinds of functional safety requirements for industrial automation systems by using single generic formulations as well as compositions of these formulations. Moreover, the catalogue contains generic formulations, which guarantee that the technique can be handled. Beside the formal specification, a safety patterns norm language allows to specify functional safety requirements in a precise and simply interpretable way by using a restricted terminology of natural language. In addition, a particular graphical notation has been developed in order to visualize complicated logical connections. The safety patterns selection, interpretation and instantiation are supported by a tool concept and by the use of multimedia technologies (interactions, textual as well as graphical descriptions and simulations). The appli¬cation of the safety patterns concept is demonstrated by means of the case study „single-track level crossing in radio-based operation“

Process Model for the Development of System Requirements Specifications for Railway Systems

Abstract: In this paper a process model for the development of system requirements specifications for railway systems is introduced. Demands of the approval of system requirements specifications, which arise from recent European railway standards, are taken into account. The aim is to obtain a system specification, which is unambiguous and easy to understand for all parties involved and in which safety aspects are considered in detail. Correlations between the development of a precise system specification, the performance of safety relevant correctness checks and the performance of risk analysis are presented. Especially the identification, specification and formalisation of safety requirements are treated with regard to correctness checks referred to safety aspects by using model checking. It is also demonstrated how different techniques of risk analysis can be supported by a system model in diagrams of the Unified Modelling Language (UML). This work has been developed in close co-operation with the Institute of Railway Systems Engineering and Traffic Safety (IfEV), Technical University of Braunschweig, Germany within the scope of the projec

Safety-Related Application Conditions - A Balance between Safety Relevance and Handicaps for Applications

Abstract. Railway standards prescribe the use of Safety-related Application Conditions (SACs). SACs are demands to be observed when using a safety related system or a sub-system. The use of SACs can, however, easily be associated with difficulties. SACs of sub-systems can imply high efforts regarding their fulfillment at system level. Furthermore, SACs at sub-system level may become very obstructive for the user of the sub-system, if the safe application on system level has strong restrictions. Additionally, a large number of SACs may be very difficult to manage. In this way, SACs may obstruct the introduction of a system or a sub-system into the field. Particular hazards could arise from SACs, if they are formulated ambiguously, so that the originally intended safety-related measures are not taken at all. This paper presents the objectives and benefits of SACs and depicts difficulties and challenges associated with the use of SACs. The paper not only explains what should be the SAC content but also the quality criteria, the conditions for SAC creation and SAC fulfillment are described. The SAC management process introduced at Thales Rail Signalling Solutions GmbH is outlined. On the one hand, this process shall support the quality of SACs and on the other hand reduce the effort for SAC creation, fulfillment and evidence